-
Notifications
You must be signed in to change notification settings - Fork 25
Fix performance of DPF vector #2249
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
✅ All tests successful. No failed tests found. Additional details and impacted files@@ Coverage Diff @@
## master #2249 +/- ##
==========================================
+ Coverage 83.75% 83.82% +0.07%
==========================================
Files 90 90
Lines 10388 10396 +8
==========================================
+ Hits 8700 8714 +14
+ Misses 1688 1682 -6 |
…ix/perf_issue_dpf_vector
…s/pydpf-core into fix/perf_issue_dpf_vector
|
||
# The updated version of the DPF vector will always be committed to DPF. | ||
# Ideally, this should be set to True only when modified, however this is not possible to do that efficiently. | ||
# Consequently, for performance reasons, it's much better to always commit the vector to DPF rather than |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cbellot000 is this also true in the case of a huge vector in gRPC on a remote machine with a high ping?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My point is that performance improvements reported are for gRPC communications with a local server, is that right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
since it's twice faster, I think that it should be safe to assume that it will as fast
closing #2201
DPF vector became slow because they were always checking if the modification of the vector by
Why performance changed between 0.13.6 and master?
Before 0.13.7.dev, it was hard coded that in process dpf vector wouldn't "check modification" and though bypassed dpf server logic. 0.13.7.dev is now relying on DPF server logic for updating or not dpf vector.
Proposed fixes
Benchmark
Test is taken for #2201, changing params are: